I. Related Invention
The present invention is related to U.S. Pat. No. 09/614,087), titled “Technique for Synchronizing Security Credentials using a Treated Authenticating Domain”, which is commonly assigned to the International Business Machines Corporation (IBM) and which was filed concurrently herewith on Jul. 11, 2000.
II. Field of the Invention
The present invention relates to computer security, and deals more particularly with a method, system, and computer program product for synchronizing security credentials of users and/or groups of users between directories, operating system platforms, and/or registers.
Description of the Related Art
It is common to have several user registries for an enterprise, and large enterprises may have hundreds of them. “Registry”, as used herein, refers to both directories and other types of user registries (including operating system registries), wherein various types of information about users is persistently stored. Examples of user registries include the SecureWay® directory from the International Business Machines Corporation (“IBM”) and Domino™ 5 directory from the Lotus Development Corporation (“Lotus”). Examples of operating system registries include the Microsoft® Windows NT® domain Security Accounts Manager database and the OS/390® RACF® product from IBM. (RACF® is an IBM licensed program that provides access control by identifying users to a system, and verifying those users; authorizing access to protected resources; etc. “SecureWay”, “OS/390”, and “RACF” are registered trademarks of IBM. “Domino” is a trademark of Lotus. “Microsoft” and “Windows NT” are registered trademarks of Microsoft Corporation.)
The information stored about users in registries of this type typically includes the user's identification (using, for example, a relatively short user identifier or “user ID” which may be associated with the user's actual name), password or other type of security credential, and access privileges (referred to equivalently herein as “permissions”), and may contain other information such as the user's preferences for various aspects of his or her system. The term “password” will be used hereinafter to refer to whatever type of security credential(s) or shared secret(s) are required to be known to the user (or other authenticating principal, such as a systems administrator or authenticating server) and registry for purposes of authenticating the user with the registry, whether it is an actual password, a personal identification number (PIN), a security token of some type, or other similar information (including stored biometric information such as a retinal scan or fingerprint).
As businesses increasingly open their corporate information technology assets to use by non-employees—for example, by enabling consumers and other businesses to enter into e-commerce transactions—the number of registries and the amount of information stored in them will continue to increase. At the same time, the efficiency of accessing a system's registries to locate and verify a user's permissions becomes of even more importance as a discriminating factor among competing businesses. As registries proliferate, it is desirable to keep the information stored in them synchronized. This enables the administrative burden of maintaining the directories to be minimized, while at the same time reducing the amount of system overhead required to authenticate a system's users in order to provide those users widespread access to the applications which they are authorized to use.
One type of registry synchronization tool which is known in the art is referred to as a “meta-directory”. A meta-directory is logically a directory of directories. Meta-directory tools keep user registries and directories synchronized with one or more central directories. A central directory uses agent technology or various directory access protocols to interrogate the contents of the user registries and directories, and then joins them into a single logical view. The result of this operation is then used to update the contents of each individual directory or registry, so that the information in each matches the information in the central directory. Examples of such tools include the InJoin™ Meta-Directory from Critical Path, Inc., and the DirXML product from Novell, Inc. Other tools, in addition to meta-directory software, provide similar techniques to synchronize user IDs (and sometimes other information) between various registries and directories. (“InJoin” is a trademark of Critical Path, Inc.)
A problem with existing synchronization tools is that they often fail to synchronize the security credentials of the users, and in particular, the existing user password values. This is because most registries provide no programmatic means of discovering a user password value: thus, it is not possible for the existing password value to be retrieved from the registry and preserved when the registered information is propagated to other registers. Instead, the synchronization tool may simply ignore the existing password value, and propagate the remaining information, thereby synchronizing all information except for the password. Or, the synchronization tool may enable a system administrator to force each user password to some new value, where this new value is then propagated (along with the user's other registered information) to the other registries being synchronized. Either approach is unsatisfactory. In the former case, the user cannot be authenticated for system access any more efficiently than before the propagation, because the stored password remains stored in the single, original directory. To solve this problem, the system administrator must define a new password for the user in each registry to which the user's information has been propagated, leading to the same problem as in the latter case discussed above. The problem with this latter case is that the user now has access permissions which are protected using a password with the user doesn't known. The new password value must be communicated to the user before the user can access the protected resources associated with that password. As will be obvious, this can be a huge administrative burden when the information for many users is being propagated. Furthermore, distribution of the password value may introduce security exposures into the system.
Maintaining the user's original password is required in order that the user's access to protected resources continues to function seamlessly and without interruption after the propagation of security credentials among registries. If the user is accustomed to typing in a particular ID and password value to access some protected resource, that same ID and password value need to be reflected in all propagated copies of that user's access permissions for the resource so that the user can continue to use (and remember) his or her original ID and password. It is not possible to simply copy an area of storage in a registry where a user's password is stored, and then use that as the user's password in an outgoing replication message. This is because the passwords are not typically stored in a recoverable form. Rather, a version of the password which has been cryptographically transformed, for example by applying a one-way hashing function to the original password, is stored as a hexadecimal value. While computation of the transformed value can be repeated for purposes of authenticating the user (i.e. by obtaining the user's password from the user again, recomputing the hash, and then comparing this new hash value to the stored hexadecimal value), the one-way property of the hashing algorithm makes it computationally infeasible to recover the password from the stored hexadecimal value. Propagating this stored hexadecimal value does not provide a general solution for synchronization of the user's password among registries, because each directory uses its own hashing algorithm (unless the directory software is identical) and thus would be unable to generate a hash value from a given input user ID which would match the stored value which was previously computed by a different registry. Some directories may encrypt passwords prior to storing them, rather than using a hashing function, where the encryption key that is used is then separately stored so that a decryption process can be applied to recover the original password value. Directories of this type, however, make the key location secret so that only the directory itself can get the plaintext value of the password.
U.S. Pat. No. 5,867,646 to Benson et al., titled “Providing Secure Access for Multiple Processes Having Separate Directories”, teaches a technique for enabling system users to access multiple processes within a system where each of the processes may have its own directory. A particular user may have a different user ID, and a different password value, in each directory. A cross-reference table is created to correlate the user's different IDs. After completing a secure log-on to a first process (e.g. the operating system), access to other processes is provided transparently—that is, without requiring a second security check—by consulting the cross reference table. (The possibility of using a second security check is provided, however.) The effect of this technique is to ignore the separately-stored password values for the subsequently-accessed systems (except in the case of the second security check). No password synchronization nor propagation technique is defined.
An article entitled “Partial Containment Structure for Inegration [sic] of Distributed Computing Environment and Local Registries” published in Volume 38, No. 9 (September 1995) of the IMB Technical Disclosure Bulletin (“TDB”) describes a password synchronization technique which enables a single log-on. A user may have multiple IDs and passwords defined in local registries, and a different ID and password defined as a principal in a DCE (Distributed Computing Environment) registry. The technique which is described is very similar to that which has been described above for U.S. Pat. No. 5,867,646. Here, a mapping is created between the DCE principal ID and the one or more local user IDs, and this mapping is used to link the different identities of a particular user. The mapping is created as user IDs are extracted from local registries, and imported into the DCE registry. However, there is no teaching of importing the user's password(s) during this process, nor is there a discussion of whether such multiple passwords continue to be used following the import process. The TDB article does discuss synchronizing in terms of updating a user's locally-stored security information from the central DCE registry, but only in terms of subsequent changes which are made to a password. There are several shortcomings in the approach which is discussed. First, the user's original password is apparently ignored, with the resulting problems which have been previously described. There is also no discussion of how a password change initiated at a local system is to be intercepted, such that the updated value can be securely relayed to the central DCE registry. Finally, regardless of whether the password change is initiated in the DCE registry or in the local registry, it is unclear whether, or how, the password change process is authenticated to the other party (the local registry or DCE registry, respectively) unless the original passwords were the same to begin with. Thus, no solution is provided for synchronizing the original set of passwords.
U.S. Pat. No. 5,862,323 to Blakley et al., titled “Retrieving Plain-Text Passwords from a Main Registry by a Plurality of Foreign Registries”, and related U.S. Pat. No. 5,832,211, also to Blakley et al., titled “Propagating Plain-Text Passwords from a Main Registry to a Plurality of Foreign Registries”, teach a technique for password synchronization which adds a new attribute to a master registry (which is DCE, in the preferred embodiment), this new attribute being a plaintext password attribute. Most registries do not allow plaintext passwords to be stored, and secure registries do not allow retrieval of an existing password from the registry for creating a plaintext version thereof (as has been discussed above).
Accordingly, a need exists for a technique by which security credentials can be securely synchronized and propagated among multiple directories, operating system platforms, and registries.